Nothing is free

Listening the Telco's advertisments our homes should be surrounded by fiberoptics and multimegabit-per-second last miles.
This is partially true, at this can be tested through these pages.

The way in which this server transmits the stream is really live, without any possibility of local cashing, thus enhancing the drawbacks of any delivery inconvenience.
As known, the reduction of the information entropy to squeeze the bitrate, makes the stream highly sensible to the unavailability even of small but significant portions of information.
This may affect the quality of experience.
It can be felt comparing the reception of the same stream at different bitrate and size, at 3-400 Kbps and 1500 Kbps, and -- as recalled above -- the bitrate is tightly required.
In h265 to reach level of compression higher than h264, the concept of Group of Picture (GoP) disappears, replaced by the Coding Unit (see below).
This extension of the single Coding Unit make the stream extremely sensible to any small lack. In this case, if the available bandwidth is lower than 1.8 Mbps there is the risk to get images like these below



These images from a Vodafone ADSL (not fiber backed) at my home. of 1.5 Mbps stream.

To avoid this side effect you need to add or enforce the Forward Error Correction (FEC) to the Transport Stream as done in broadcast transmissions (such as DVB), thus partly vanishing the further compression obtained. Another strategy is that of distributing the spikes of bandwidth excess requirements on the entire stream. But increase the latency and make this approach not suitable for live events.

The advantage of transferring slices of the file to the client, that avoid such kind of problems in h264, in h265 becomes more dangerous: the potential lack of reference frame for a longer time than h264 makes more critical the splitting of the movie as done in DASH or HLS delivery.

Squeeze, squeeze always squeeze more

H265 means progressive HD at less than 3 Mbps. It introduces a lot of news. It supersede the concept of GoP and macroblock dividing the frame in slices and/or tiles (rectangular) with Coding Tree Unit (CTU) divided in Coding Units (CU) after the motion estimation. The Coding Unit (now up to 64 pixel) which is the replacement of macroblock but in h265 any CU has its own evolution and story, while until h264 it used to work at frame level. CTUs are grouped in Slices (any number of CTUs) and/or Tiles (rectangular) depending on their temporal and spatial evolution.

To understand something about how h265 works you can get something more readable from Vcodex articles An introduction to High Efficiency Video Coding or its full version (that require a login). Finally you can download the officila ITU/IEC 23008-2 standard in pdf free from ITU (quite tricky but complete).

If you're going to evaluate the hevc quality, you must remember that it is much more complex to decode than h264. Hevc is only progressive (but we were already accustomed to deal with progressive videos on the web): the problem is related to the decompression algorithm that is about thrice complex than h264.

This is the load of the decompression of 720p stretched to full screen on my laptop: about the 80%.

My dual core laptop, quietly able to decode progressive HD in h264, exhibit its inadequacy to decode 720p hevc. If the browser is not the only window open, the entire computational power can be easily drained.

Click here if the reproduction is jerky (processor power or network conditions.